Monitoring messages during execution of a message flow

ABSTRACT

Provided are an execution monitoring tool, a method and a computer program product for monitoring a message processing program or system. The execution monitoring tool identifies locations within the message processing program corresponding to a predefined set of execution progress stages, and inserts execution progress report generator components at these locations. Execution progress reports (including a representation of the message contents and structure) are then sent to the execution monitoring controller which maps the report data to its own representation of the program to determine the current position within an execution program. The message contents and structure, as well as the structure of the program and the current execution position, are displayed during execution on a test system. The execution reports include the current execution status as well as the position within the execution flow. The invention is advantageous for debugging a visual message flow, which represents a sequence of message processing operations as a set of nodes and connections between the nodes. A set of debug nodes for generating the execution progress reports are automatically inserted in the message flow before executing it on a test and debugging system, and these debug nodes send execution progress reports to a debug controller.

FIELD OF INVENTION

[0001] The present invention relates to monitoring program execution andthe effects of program execution in a visual programming environment.

BACKGROUND

[0002] Visual programming techniques and tools allow computer programsto be developed by manipulation of visual images representing objects,providing an alternative to conventional alphanumeric-character-basedprogramming languages. Such techniques and tools make the task ofcomputer program development easier for programmers than was possiblewith earlier non-visual programming languages, and make programmingaccessible to non-expert programmers. Visual programming has enabledmore rapid prototyping and application program development, and hasgenerally enabled users to focus on what functions they want theirprogram to perform by greatly reducing the requirement to learn aboutprogramming languages and the internal workings of a computer.

[0003] Nevertheless, it remains the case that the available visualprogramming tools and languages, such as VisualBasic from MicrosoftCorporation, are mainly used for building a user interface (selectingand positioning user interface components such as buttons, scrollbars,etc, and scripting their behaviour). The user is often required to relyon conventional programming techniques for implementing the mainbusiness logic underneath the user interface.

[0004] As with other computer programs, programs developed using visualprogramming techniques require debugging, but in the past many visualprogramming tools have not enabled visual debugging. That is, the userhas been provided with source level debug information which has requireda greater level of understanding of languages and systems than theoriginal visual programming task. More recently, it has been recognisedthat visual programmers should be provided with visual reporting of anyproblems which require debugging, thereby matching the problem reportingstyle to the requirements of a typical visual programmer rather thanrelying on non-intuitive source code level debug information.

[0005] PROGRAPH 2, described in Cox et al, “Using a PictorialRepresentation to Combine Dataflow and Object-Orientation in a LanguageIndependent programming Mechanism”, Proceedings International ComputerScience Conference, pp. 695-704, 1988, is one example of a visualprogramming environment which has integrated editing and debugging, andin which operations are represented pictorially as nodes of anhierarchical dataflow. Sets of windows can be opened to exploredifferent levels of detail within a program and errors are responded toby opening a window containing the operation in question, flashing therelevant icon and generating an explanatory message.

[0006] To enable debugging of an hierarchical program, PROGRAPH 2 andother known visual programming tools rely on access to the program'sexecution stack to monitor execution of the program and hence toindicate the hierarchical structure and locations within it. A program'sexecution stack is the data area or buffer of the data processingapparatus on which the program is executing which is used for storingcontext information of the sequence of invocations for operations thatare performed during execution of the program. Storing such contextinformation during program execution is essential for successfulexecution of an hierarchical (or nested) program —to enable a programwhich jumps to a subroutine to return to the correct point in theprogram after executing the subroutine. The reliance of known debuggerson the execution stack is because an hierarchical program is typically“flattened” into a linear flow for execution, such that the contextwithin the hierarchical structure of a particular point in a program isnot apparent from the executing program itself (subroutines appear asmacros within a linear flow). An interpreter within PROGRAPH 2 shows thestate of the execution stack in a special window and can illustrate theexecuting operations via a set of windows showing different levels ofthe hierarchy. This is fine for typical visual programmers, becausetheir programs are limited to a single system and the program executionstack is available on the same system as the development and debuggingtools. However, such a debugging solution could not be used if theexecution stack is inaccessible from the debugger.

[0007] Another solution which allows debugging of dataflow diagrams in aunified visual environment without repeatedly switching between buildand debug modes of operation is the PANTA development framework fromMetrowerks AG (formerly HIWARE AG). The user merely switches betweenedit and debug windows.

[0008] U.S. Pat. No. 6,055,369 discloses a visual programming apparatusfor creating a program with a visual user interface made up of multiplescreens, including a unit for creating a screen flow comprising a flowof processes which includes a compressed representation of each of themultiple screens. Information can be extracted from the screen flow andused to generate source code. This assists the user in understanding theassociation between screens and hence designing, creating and testing avisual program.

[0009] U.S. Pat. No. 5,850,548 discloses a visual programmingenvironment based on an hierarchical data flow model. Functional codecomponents can be constructed either using conventional programmingtechniques or using a visual programming language, and these componentsare then connected together in an hierarchical data flow model forsending “messages” to and receiving “messages” from each other. Theon-screen representation of the data flow aids debugging.

SUMMARY OF INVENTION

[0010] The present invention provides improved visual executionmonitoring capability for computer programs.

[0011] The invention according to a first aspect provides a visualexecution monitoring tool for monitoring a message processing program orsystem, wherein the tool enables the contents of a message to be viewedby a user while the message processing program is being executed,enabling the user to monitor the effects of execution.

[0012] The invention according to a second aspect enables automatedinstrumentation of computer programs, inserting execution progressreport generator components which send their reports to an executionmonitoring controller when certain stages of execution are reached, suchthat the execution monitoring controller can use the received reports totrack execution progress.

[0013] According to the first aspect of the present invention, there isprovided a visual execution monitoring tool for monitoring execution ofa message processing program, comprising: one or more components forgenerating program execution progress reports upon reaching predefinedstages of program execution, the execution progress reports including arepresentation of the current contents of a message being processed bythe message processing program, and for sending the execution progressreports to an execution monitoring controller; an execution monitoringcontroller which is responsive to receipt of said execution progressreports for generating, during execution of said message processingprogram, a visual representation of the message contents.

[0014] The message contents included in the progress reports andrepresented visually preferably include message data and informationrelating to the message structure (e.g. Header fields). This may be anXML representation of the message.

[0015] The execution monitoring tool preferably includes means forinputting a test message for testing execution of the message processingprogram. This may comprise a message generator which is triggered tocreate and input a message by user definition of message data or messageheaders, user selection of a message type, or reading a message from anexternal file. The execution monitoring tool preferably also enables aprogrammer to change the message content when execution is stopped at abreakpoint in the program, and thus affect further execution.

[0016] The execution progress reports preferably include currentexecution status information from which the execution monitoringcontroller can generate a visual indication of execution status, such asthe occurrence of exceptions. The execution progress reports preferablyalso include information relating to the position within the messageprocessing program's structure corresponding to the current stage ofprogram execution. The execution monitoring controller preferablymaintains information representing the structure of the messageprocessing program and maps received progress reports to this structure.The execution monitoring controller then generates a visualrepresentation of the message processing program's structure and avisual representation of the position within the program structurecorresponding to the stage of program execution indicated by thereceived progress report data.

[0017] The execution monitoring controller preferably maintains anupdated record of certain parts of the program's execution stack,updated from received execution progress reports. This preferablyprovides, in a storage area local to a debugger, the context ofoperation execution required for debugging the program. The sending ofreports to the execution monitoring controller may be implemented by,for example, use of TCP/IP socket connections or storing reports on astorage medium which is accessible to both the execution progress reportgenerator components and the execution monitoring controller, or analternative.

[0018] According to the invention, the structure of an hierarchicalvisual message processing program can be displayed, together with thecontents of a propagating message, during test execution. Thisfacilitates debugging. This is particularly useful for monitoringexecution of an hierarchical program which is executing on a separatesystem from the execution monitoring controller, since the monitoringcontroller will not then have access to the hierarchical program'sexecution stack and it is undesirable to have to rely on accessing aremote system's log records to track execution progress. The inventionwill also prove useful for monitoring execution of a distributedhierarchical program in which processing components of the program areexecutable remotely from each other, since no single system's programexecution stack would then provide the full context within the programhierarchy.

[0019] According to a preferred embodiment of the invention, the visualrepresentation of the hierarchical visual program represents processingcomponents of the program as interconnected nodes of an hierarchicalprogram flow. The components for generating progress reports arepreferably also implemented as separate nodes of the program flow. Thisconsistency between progress report generator components and processingcomponents allows a visual programmer to use consistent visualprogramming techniques and concepts (manipulation of visualrepresentations of separate components) to work with both types ofcomponents. Furthermore, if the execution system is separate from butconnected to the system used for programming, then no change will berequired to the program's execution system to handle the addition ofreport generator nodes and the report generator nodes need not beexposed to a normal user when the program is run.

[0020] In a preferred embodiment of the invention, the monitoring toolautomatically instruments the program flow with progress reportgenerator nodes, in response to analysing the program to identifycertain program execution stages. This automated insertion of reportgenerator nodes reduces the work involved in enabling executionmonitoring.

[0021] The visual programmer is preferably provided with the capabilityto set breakpoints within the program at the positions of selectedreport generator nodes—for example at input or output terminals ofprocessing nodes, on connections between nodes, or other significantpoints in the program flow. Setting of breakpoints is well known withinvisual programming.

[0022] The progress report generator nodes preferably include debugnodes which generate execution progress data for debugging, and theexecution progress monitoring controller comprises a debug controlleradapted to determine the position within an hierarchical programstructure corresponding to the current state of program execution. Thedebug controller visually displays message contents and otherinformation which is useful for debugging, such as an indication of thedetermined position.

[0023] A tool according to a preferred embodiment of the presentinvention is a visual programming and execution monitoring tool fordeveloping message processing and forwarding programs, in which theprocessing components are represented as nodes of a visual message flow.The message flow can be debugged by executing it on a test and debugsystem which is connected for communication with a development system.Run-time execution can be simulated by inputting test messages to themessage flow, sending execution progress reports to an executionmonitoring controller, and using the controller to monitor processing ofthese messages and display the results to the programmer. The processingcomponents of the test and debug execution system may be distributedacross a plurality of interconnected data processing systems. In anenvironment in which program components may be executing on one or moresystems remote from a debugger, prior art debugging solutions which relyon access to a single system's execution stack cannot be used and thealternative of a debugger which relies on accessing the log records of aremote different system would not achieve desirable performance.

[0024] According to the preferred embodiment, program developmentcapability including debug editing capability is integrated with theexecution monitoring tool, such that development and debugging can beperformed without switching modes between execution monitoring andediting and without switching from a development system to anunconnected, dedicated debugging system.

[0025] A programmer wishing to debug a visual program which isrepresented by a message flow provides a set of input messages (forexample, the programmer either defines messages, selects predefinedmessages or runs communicating partner test applications to generatemessages), uses the execution monitoring tool to monitor the actionsperformed on the message during execution, and responds to any visualindications of the occurrence of exceptions by editing the program usingvisual programming techniques. The structure and contents of the messagecan be tracked at all points in the execution of the message flow andthe visual program can be developed, monitored and edited within theintegrated development and debugging environment until it has beenverified as working properly.

[0026] Furthermore, according to the preferred embodiment, the user'sview of the visual message flow representation of the developed programis consistent with the user's understanding of messages flowing betweennodes of a message processing and forwarding network, and this minimizesthe requirement for a visual programmer who is familiar with messagingto learn new concepts before starting programming of message flows.

[0027] Such a visual programming and execution monitoring tool can beintegrated within a message broker within a messaging network, orprovided as a tool for use with such a broker. This is particularlyadvantageous since message brokers can provide a very valuableintermediary message processing and forwarding service for applicationprograms connected via a messaging network, particularly in complexnetworks, and yet message brokers are required to perform different setsof operations for different enterprises and users and differententerprises will have very different combinations of new and legacysystems which are required to interoperate via the message broker. It istherefore particularly beneficial to provide visual programming anddebugging capability to enable rapid customisation of the broker andintegration with other systems. A message broker framework supportingmodular plug and play components can benefit greatly from the presentinvention. Furthermore, enterprises who have a message broker inproductive use for routing and transforming messages will typicallyprefer a runtime simulation or a test and debugging execution systemwhich is integrated within the development environment, rather thanextending their run-time production system. This is preferred both tooptimize the performance of their developers and to protect theirbusiness-critical production system from programming errors.

[0028] In a further aspect, the invention provides a method formonitoring execution progress of a message processing program, includingthe steps of: identifying a set of locations within the messageprocessing program corresponding to a predefined set of executionprogress points, and inserting at each of said locations a component forgenerating program execution progress reports when the predefinedexecution progress points are reached during execution of the messageprocessing program; responsive to input to the message processingprogram of at least one message, initiating execution of the messageprocessing program to process said at least one message and to generateprogram execution progress reports including a representation of thecurrent message contents, and to send the reports to an executionmonitoring controller; responsive to receipt of said progress reports bysaid execution monitoring controller, generating a visual representationof the current message contents.

[0029] In a further aspect, the invention provides a computer program(preferably implemented as a computer program product comprising programcode recorded on a computer readable recording medium) for controlling adata processing apparatus on which it runs to perform a method as above.

[0030] A computer program product according to a further aspect of theinvention, which comprises program code recorded on a computer-readablerecording medium, implements a visual execution monitoring tool formonitoring execution of a message processing program in which theprogram code of the tool comprises: one or more components forgenerating program execution progress reports upon reaching predefinedstages of program execution, the execution progress reports including arepresentation of the current contents of a message being processed bythe message processing program, and for sending the execution progressreports to an execution monitoring controller; an execution monitoringcontroller which is responsive to receipt of said execution progressreports for generating, during execution of said message processingprogram, a visual representation of the message contents.

[0031] In a further aspect of the invention, there is provided a visualexecution monitoring tool for monitoring execution of a computerprogram, comprising: means for identifying locations within a computerprogram corresponding to a predefined set of execution progress points,and for inserting at each of said locations a component for generatingprogram execution progress reports when the predefined executionprogress points are reached during execution of said program; meansresponsive to said components generating said execution progress reportsfor sending the progress reports to an execution monitoring controller;an execution monitoring controller for receiving said execution progressreports and for generating, during execution of said computer program, avisual representation of the received execution progress report data.

BRIEF DESCRIPTION OF DRAWINGS

[0032] Preferred embodiments of the present invention will now bedescribed in more detail, by way of example, with reference to theaccompanying drawings in which:

[0033]FIG. 1 is a schematic representation of a message integrationframework for implementing the invention according to a firstembodiment, and showing an underlying messaging support program andother connected programs for use in a data processing network;

[0034]FIG. 2 shows an example message flow for processing and forwardingstock market data;

[0035]FIG. 3 is a screen shot of a GUI of an execution monitoring anddebugging tool according to an embodiment of the invention;

[0036]FIG. 4 shows a sample message flow;

[0037]FIG. 5 shows the relationships between components of the debugger;

[0038]FIG. 6 shows the architecture of an embodiment of the invention inwhich a debugging system is separated from a run-time development brokerframework;

[0039]FIG. 7 shows an example message flow;

[0040]FIG. 8 shows the message flow of FIG. 7 after insertion of debugnodes;

[0041]FIGS. 9 and 10 show the communication protocol of a debugprocessing node and the debugger controller, respectively, according toan embodiment of the invention; and

[0042]FIG. 11 shows an example nested message flow.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0043] An embodiment of the present invention will be described belowwith reference to FIG. 1 which shows a message integration architecture10, underlying messaging support 20, and other connected computerprograms 30, 40 of a data processing system within a messaging network.A visual programming and program execution monitoring tool isimplemented in a Control Center component 50 of the message integrationarchitecture 10, for developing, testing and visually debugging messageflows 80 for running on a message broker 60.

[0044] Before describing the invention in detail, an introduction tomessage queuing, message brokers and message flows will be helpful.

[0045] The ability to rapidly adopt, integrate and extend new andexisting data processing technologies has become essential to thesuccess of many businesses. Heterogeneity and change in data processingnetworks has become the norm, requiring communication solutions whichachieve interoperability between the different systems.Application-to-application messaging via intelligent middleware productsprovides a solution to this problem.

[0046] Messaging and Message Brokers

[0047] For example, IBM Corporation's MQSeries messaging and queuingproduct family are known to support interoperation between applicationprograms running on different systems in a distributed heterogeneousenvironment. Message queuing and commercially available message queuingproducts are described in “Messaging and Queuing Using the MQI”, B.Blakeley, H. Harris & R. Lewis, McGraw-Hill, 1994, and in the followingpublications which are available from IBM Corporation: “An Introductionto Messaging and Queuing” (IBM Document number GC33-0805-00) and“MQSeries—Message Queue Interface Technical Reference” (IBM Documentnumber SC33-0850-01). The network via which the computers communicateusing message queuing may be the Internet, an intranet, or any computernetwork. IBM and MQSeries are trademarks of IBM Corporation.

[0048] IBM's MQSeries messaging products provide transactional messagingsupport, synchronising messages within logical units of work inaccordance with a messaging protocol which gives assured once andonce-only message delivery even in the event of system or communicationsfailures. MQSeries products provide assured delivery by not finallydeleting a message from storage on a sender system until it is confirmedas safely stored by a receiver system, and by use of sophisticatedrecovery facilities. Prior to commitment of transfer of the message uponconfirmation of successful storage, both the deletion of the messagefrom storage at the sender system and insertion into storage at thereceiver system are kept ‘in doubt’, and can be backed out atomically inthe event of a failure. This message transmission protocol and theassociated transactional concepts and recovery facilities are describedin international patent application WO 95/10805 and U.S. Pat. No.5,465,328.

[0049] The message queuing inter-program communication support providedby the MQSeries products enables each application program to sendmessages to the input queue of any other target application program andeach target application can asynchronously take these messages from itsinput queue for processing. This provides for assured delivery ofmessages between application programs which may be spread across adistributed heterogeneous computer network, without requiring adedicated logical end-to-end connection between the applicationprograms, but there can be great complexity in the map of possibleinterconnections between the application programs.

[0050] This complexity can be greatly simplified by including within thenetwork architecture a communications hub to which other systemsconnect, instead of having direct connections between all systems.Message brokering capabilities can then be provided at thecommunications hub to provide intelligent message routing andintegration of applications. Message brokering functions typicallyinclude the ability to route messages intelligently according tobusiness rules and knowledge of different application programs'information requirements, using message ‘topic’ information contained inmessage headers, and the ability to transform message formats usingknowledge of the message format requirements of target applications orsystems to reconcile differences between systems and applications.

[0051] Such brokering capabilities are provided, for example, by IBMCorporation's MQSeries Integrator products, providing intelligentrouting and transformation services for messages which are exchangedbetween application programs using IBM's MQSeries messaging products.

[0052] Support for both management and development of message brokeringapplications can be implemented in a message broker architecture toprovide functions including publish/subscribe message delivery, messagetransformation, database integration, message warehousing and messagerouting. Message flows are a visual programming technology which supportall of these broker capabilities and greatly ease the task of managementand development of message brokering solutions.

[0053] Message Flows

[0054] A message flow is a visual program which represents the sequenceof operations performed by the processing logic of a message broker as adirected graph (a message flow diagram) between an input queue and atarget queue. The message flow diagram consists of message processingnodes, which are representations of processing components, and messageflow connectors between the nodes. Message processing nodes arepredefined components, each performing a specific type of processing onan input message. The processing undertaken by these nodes may cover arange of activities, including reformatting of a message, transformationof a message (e.g. adding, deleting, or updating fields), routing of amessage, archiving a message into a message warehouse, or merging ofdatabase information into the message content. There are two basic typesof message processing nodes: endpoints and generic processing nodes.Endpoints represent points in the message flow to which messageproducers may send messages (input nodes) or from which messageconsumers may receive messages (output nodes). Endpoints are associatedwith system queues and client applications interact with an endpoint byreading from or writing to these queues. Generic processing nodes take amessage as input and transform it into zero, one, or more outputmessages. Each such message processing node has a set of InTerminalsthrough which it receives messages, and a set (possibly empty) ofOutTerminals, through which it propagates the processed message. Messageprocessing nodes have properties which can be customized. Theseproperties include expressions that are used by the processing node toperform it's processing on input messages.

[0055] A message flow is created by a visual programmer using visualprogramming features of the message broker. This involves placingmessage processing nodes on a drawing surface, and connecting the outterminal of one node to the in terminal of another node. Theseconnections determine the flow of the messages through the messageprocessing nodes. A message flow can contain a compound messageprocessing node which is itself a message flow. In this way messageflows can be built modularly, and specific message processingfunctionality can be reused.

[0056] Message Flow Execution

[0057] Message flows are executed by an execution engine that can read adescription of a message flow, and invoke the appropriate runtime codefor each message processing node. This will be referred to later. Eachmessage flow has a thread pool which can be configured to have between 1and 256 threads. When an input node for a message flow is constructed ittakes one thread from its thread pool and uses it to listen to the inputqueue. A single thread carries a message from the beginning of the flowthrough to the end, and hence the thread can be used to identify themessage as it passes through the flow.

[0058] The queuing of an input message on that input queue initiatesexecution of the message flow on the queued message. The message is thenpropagated to the target nodes of the connectors originating from theoutput terminal of the input node. If there is more than one outgoingconnector, copies of the message are created and handled independentlyby the subsequent nodes. If the node is an output node, the message isdelivered to the associated message queue; otherwise the processing nodewill create zero or more output messages for each of its outputterminals. Messages are propagated to subsequent nodes as describedabove.

[0059] A message processing node will process an input message as soonas it arrives and retain no information about the message when it hasfinished its processing. A processing node might output more than onemessage of the same type through an output terminal and several copiesof the same message might be propagated if there is more than oneconnector originating from an output terminal; all of these messages areprocessed independently of each other. A processing node does notnecessarily produce output messages for all of its outputterminals—often it will produce one output for a specific terminaldepending on the specific input message. Also, a node might producemessages for output terminals that are not connected to other processingnodes, in which case the message is not processed further.

[0060] A Message Flow Example

[0061] To illustrate the use of a message flow, a sample scenario willnow be described in the context of sending stock market data betweenapplications via a message broker. The information which the involvedapplications wish to share is included in the following messages:

[0062] NYSEtrade message that contains information: date, companysymbol, company name, quote price, total value traded

[0063] FTSEtrade message with the same information in identical format

[0064] AMEXtrade message that contains date, company name, quote priceand amount traded.

[0065] The information that applications want to acquire is detailedbelow:

[0066] Rationalized trades—all trades in a consistent data format—neededfor known trading analysis application A.

[0067] Major trades—rationalized trades with ‘netvalue’ greater than$100,000 —these can be logged in a message warehouse and delivered toapplication C, which connects intermittently to do historical analysis.

[0068] Price to Earnings ratio (PE) Update—triggered by earningsreports, computed and added to earning report data and delivered toapplication B which analyses PE changes.

[0069] Furthermore, it was decided in this example to publicize thestream of major trades.

[0070]FIG. 2 shows a message flow that implements the above describedfunctionality. To respond to the needs of each application, the messageflow contains the following processing nodes:

[0071] Computel node—merges the matching messages from three sourcesinto one stream, and computes extra fields to standardize stock tradeinformation from AMEX to match that of the other stock trade publishers;converting company name to symbol may require a table lookup. A Computenode is capable of constructing a new message out of the field contentsof the input message, default values, or constants.

[0072] A combination of nodes: Check1, and Extract1—that do theselection to identify major trades, i.e., test for value greater than$100,000. An Extract node derives an output message from the contents ofan input message by copying only those elements of the input messagewhich are explicitly specified. Any elements of the output message whichare not explicitly specified will either have null values or will simplynot exist. A Check node checks whether the format of a message arrivingon its input terminal matches the specification defined by the messageproperty attributes.

[0073] DataInsert1 node—logs the major trades in the message warehouseto make them available for intermittently connected historical analysisapplications. A DataInsert node may be used to insert a new row into atable in a specified database.

[0074] Compute2 node—computes the price to earnings ratio and adds it into the message data for application B.

[0075] Publication node—to publicize the stream of major trades. ThePublication node may be used within a message flow to represent a pointfrom which messages are “published”, that is a point from which messagesare transmitted to a set of subscribers who have registered interest ina particular set of messages.

[0076] Message Flow Debugger

[0077] Once a message flow has been programmed, the message flowdeveloper's next step is to verify that the flow behaves correctlybefore integrating it into an operational messaging system. In order toverify the behaviour of a message flow, a developer typically wants toprovide some input messages to the message flow and execute them througha debugger to see that the expected actions are executed. Usingconventional source-level debuggers for this task would be difficult fortypical message flow programmers. Message flow programmers want to beable to test and debug their flows within the development environment.

[0078] An integrated message flow development and debugging environmentaccording to the present invention provides a message flow developerwith debug capabilities as described below together with some editingcapabilities, such as modifications of the message flow structure ornode properties and the ability to modify propagating messages atbreakpoints during message flow execution. The debugger graphical userinterface (GUI) of the message flow debugger is divided into four mainparts which enable the message flow developer to track a message fromthe initial queue, through the message processing nodes, until itreaches the target queue. The four parts are shown in FIG. 3:

[0079] 1. The Message Flow View pane 120—in which the message flow thatis currently being executed is displayed. In this pane the programmercan set breakpoints, zoom into compound nodes, and inspect properties ofa node. The programmer is able to see the hierarchical structure of themessage flow, and the location within that structure corresponding tothe current stage of execution is shown by displaying an indicator ontop of the message flow diagram. How this is achieved for a message flowwhich is flattened for execution will be described in detail later.

[0080] 2. The Execution Stack View pane 130—in which the dynamichierarchy of the currently active message flow execution is displayed.At the initial stage of a message flow execution there is one item(corresponding to the input node of the message flow) in the stack. Whenexecution progresses, if the node being executed is primitive it isdisplayed. If the executing node is compound, and the programmer stepsinto it, then another item is pushed onto the stack corresponding to theinput node of the contained message flow. When execution of thecontained flow ends, or when the programmer selects return, thecorresponding item is popped from the stack. In this pane the programmeris able to switch between active compound nodes by selecting rows in thestack. The selected message flow is presented in the Message Flow Viewpane 120. How the execution context information is provided and storedwhen the development system is separate from the execution system willbe described in detail later.

[0081] 3. The Message Content View pane 140—in which the content of themessage being propagated through the message flow is displayed.

[0082] 4. The Information Bar 150—in which information on the currentstatus of the debug session is given, such as breakpoint encountering,debug session end.

[0083] The message flow debugger includes means for controlling thedebug session in terms of visually represented nodes and connections,and includes support for the following debug capabilities:

[0084] 1. The ability to set/delete breakpoints. A breakpoint can be setin several locations, at all levels of an hierarchical message flow:

[0085] 1.1 On an input port of a processing node, in this case executionstops before the node is performed.

[0086] 1.2 On an output port of a processing node, thus execution stopsafter the node was performed.

[0087] 1.3 On a connection between nodes, here execution stops after theconnection originator node was performed and before the target node ofthe connection was performed.

[0088] 1.4 On the entrance to a processing node (on all input ports), oron the exit from a processing node (on all output ports). A Booleancondition can be related to the contents of the message passing throughthe port to which the breakpoint is associated.

[0089] 2. Entering input to the program. The input to a message flow isa message. The programmer can select a message type out of a set ofpredefined types and then fill in the content, and/or manually definemessage header fields based on a set of supported formats, oralternatively read an existing message from an external file.

[0090] 3. The ability to inspect the message propagating through themessage flow. A message inspector view displays the current content ofthe message at all times. The programmer is able to change the messagecontent, once the execution is stopped at a breakpoint, and thus affectfurther execution. Note that the structure and contents of the messagecan be viewed throughout the debug session, and are updated whenever abreakpoint is reached, to show the effects on the message of the actionsperformed by the processing nodes.

[0091] 4. Browsing through the program components. A message flow is anhierarchical program, and the programmer is able to browse through it byselecting a compound node in the message flow diagram and zooming intoit.

[0092] 5. Run—start/resume the execution. The program is executed untila breakpoint is encountered.

[0093] 6. Step Over. Execute the next processing node and then stop.

[0094] 7. Step Into. When the next processing node is a compound node,stop after executing the in terminal of the internal message flow.

[0095] 8. Return. If selected when inside a compound node, go back tothe containing message flow.

[0096] 9. Quit. Stop the debug session.

[0097] 10. Switching between active components. When execution is insidea compound node, the programmer is able to switch to the containingmessage flow by using an execution stack.

[0098] While the debugger is active (i.e. from the time a programmerstarts a debug session to the time the programmer stops the session),the debugger is continuously in a state of waiting for a message to beplaced on any of the message flow's input queues. The debugger uses amessage generator to create a message from data inserted by a programmerand to place these messages into the message flow. Once a messageappears on an input queue, it will progress through the flow until abreakpoint is encountered. At that point, the contents of the messagewill be communicated to an execution monitoring tool which displays thecontents to the programmer, who will have an opportunity to change themessage before continuing.

[0099] The screen shot of FIG. 3, showing an execution monitoring anddebugging tool implementing the invention, will be used to help describea sample user scenario relating to the message flow of FIG. 4. Thepurpose of the message flow shown in FIG. 4 is to sort the arrivingmessages according to their topic into two different streams: themessages with ‘IBM Stock’ topic and the messages with ‘Intel Stock’topic. Other messages, which do not agree with either of these topicsare discarded. To sort the messages a Filter node is used. A Filter nodeevaluates an SQL expression against the content of the input message.The first Filter node 160 checks for messages with ‘IBM Stock’ topic.All messages that satisfy this condition are propagated through the‘true’ output port to the MQOutput node 170 called ‘IBM Out’. Themessages that do not meet this condition are propagated through the‘false’ output port to the second Filter node 180. The second Filternode checks for messages with ‘Intel Stock’ topic.

[0100] The messages that satisfy this condition are propagated throughthe ‘true’ output port to the MQOutput node 190 that is called ‘IntelOut’. All other messages are not propagated since the other ports arenot connected.

[0101] To check that the routing is done correctly, a message flowdeveloper uses the debugger to generate a message with ‘IBM Stock’topic, and sets a breakpoint at the exit from the first Filter node (onall output ports). The developer clicks the ‘Run’ button to start thedebug session. Consider a situation in which a breakpoint is encounteredon the ‘false’ port instead of on the ‘true’ port. This situation isshown in FIG. 3, where a visual indication 200 of the relevantbreakpoint location within the message flow is presented. Whenever abreakpoint is reached during the debug session, an indication oflocation within the message flow is presented to the programmer. Problemidentification information can also be visually displayed to theprogrammer (in the Information bar 150) to enable association between anidentified problem and its location within the message flow.

[0102] To examine what went wrong, the developer uses the right mousebutton to look at the Filter node properties which contain the SQLexpression. If he finds a misspelled word he can correct it. The debugsession now starts again, and the flow works correctly. Typical bugs tobe handled include: nodes connected incorrectly (outputs connected toincorrect inputs); Filter nodes with incorrect conditions; Compute nodeswith incorrect logic; Database nodes which make incorrect entries intarget databases; messages with contents which do not match expectationsof message flow; unintended feedback loops within programs which resultin infinite loops; errors in user-programmed plug-ins.

[0103] Broker Architecture

[0104]FIG. 1 illustrates the major components of a message integrationarchitecture according to an implementation of the present invention,and their relationships:

[0105] The broker domain, including one or more individual brokers 60hosting execution groups 70, that in turn host message flows 80.

[0106] The Configuration Manager 90.

[0107] The Control Center 50.

[0108] A message broker 60 can comprise a set of execution environmentshosting message flows arranged in execution groups that handle themessage traffic. Any number of brokers can be installed and configured.Together these make up the broker domain. Each broker 60 in a brokerdomain may be on a different machine, or even a different geographiclocation.

[0109] A Configuration Manager 90 stores and manages configuration dataon behalf of one or more brokers 60. It provides a single, central pointof management for the domain. Individual brokers receive theirconfiguration from the configuration manager.

[0110] The Control Center 50 implements visual programming and programexecution monitoring functions according to the invention, as the firstone of its three major capabilities:

[0111] 1. Definition of message flows and message broker configuration,message sets, publish/subscribe topology and topics.

[0112] 2. Deployment of configuration definitions to a broker domain.

[0113] 3. Runtime administration of a broker domain.

[0114] The present invention focusses on the first of thesecapabilities, and in particular on monitoring the execution of theprogram in a test and debugging system.

[0115] To achieve debugging, the Control Center 50 includes: a GUIapplication from which an execution monitoring tool is activated toenable interactive debugging; a debug controller that is responsible forcommunicating with the execution engine and controlling the debugsession; and a message generator for generating the test message fromuser-input data and providing this to the message flow. The ControlCenter may be on a different machine from the brokers.

[0116]FIG. 5 shows the relationships between these debugging componentsof the Control Center. Debug nodes 210 (described later) are insertedbetween each processing node 220 in a target message flow, and each ofthese is responded to by the execution engine 230 by invoking acommunication with the debug controller 240 every time a message passesthrough them (for example using TCP/IP communications, or placinginformation in shared storage which is accessible to both the debugcontroller 240 and the debug nodes 210, or any alternative). In certainimplementations of the invention, they also communicate with the debugcontroller once the message flow has completed delivery of the message,as the chain of message propagate calls unwinds. In the forwarddirection, a debug node communicates the node's unique identifier (this,possibly with an identifier of the original containing message flow, issufficient context information to determine the location within anhierarchical message flow since an execution stack is built up—asdescribed later), an indication of execution status, and an XML(eXtensible Markup Language) version of the message which shows themessage structure and contents. The debug controller checks the debugnode's identifier and, if it corresponds to a breakpoint set by theuser, then the debug controller displays the message in the GUI 250 andpermits the user to change it. When the breakpoint is stepped out of,the edited message is sent back to the debug node and substituted forthe original message.

[0117] In an alternative to the embodiment of the invention describedabove, the debug nodes themselves contain a breakpoint attribute todetermine which debug nodes are associated with breakpoints, and thedebug nodes only communicate with the debug controller when breakpointsare reached instead of every time a message passes through them.

[0118] The communication between the control center and theconfiguration manager, and between the configuration manager and thebroker domain is performed by using the underlying support of themessaging system (such as IBM's MQSeries message queue managersoftware—not depicted in FIG. 5). Applications communicate with thebroker by sending messages directly to the queues hosted by the queuemanager associated with the broker.

[0119] A typical scenario of the lifetime of a message flow would be:

[0120] 1. A message flow developer uses the visual programming editingand debugging capabilities of the Control Center to design a new messageflow and to verify that it executes correctly. The message flow is thenpresented to the configuration manager.

[0121] 2. The message flow is assigned by the domain expert to aspecific execution group (hosted by a message broker).

[0122] 3. The system administrator deploys this configuration to abroker domain, to make it work as part of the messaging system. This isdone via a control center command, which communicates with theconfiguration manager, which in turn communicates with the specificbroker.

[0123] 4. The message flow is now running on the broker, and is ready toprocess messages. Once a message is received on the queue associatedwith the message flow input, this message is propagated through themessage flow. The message flow continues to process messages until it istaken out of deployment.

[0124] Implementing Debugging Capabilities Within the BrokerArchitecture

[0125] A significant aspect of the invention is to allow the developerto monitor the propagation of messages through a message flow while itis executing in a test and debugging system which is separate from therun-time production environment.

[0126] Implementing such functionality could be done by extending theruntime environment with debugging capabilities (that is, designing aruntime architecture that allows debugging actions, and can run in twomodes: debug and production). However, the procedure for putting amessage flow into operational use can be quite complex, typicallyrequiring the co-operation of different roles. It is desirable to avoida message flow developer having to go through this procedure each timehe/she wants to test a message flow under development, and it is alsodesirable to avoid integrating a message flow into an operationalproduction system until its behaviour has been verified. Additionally,it is advantageous when implementing monitoring capabilities in anexisting runtime environment which does not have debugging capabilitiesto minimize changes to that environment. Furthermore, if such debugcapabilities were implemented in the runtime environment they could notbe turned on globally, such that a mechanism would be needed to allowmessage flows in production to continue running in production mode,while other message flows were being tested in debug mode.

[0127] For these reasons, testing and debugging activities are separatedfrom the run-time production system, and the deployment procedure is notexposed to the developer. Such a solution is depicted in FIG. 6.Separation of testing and debugging activities from the operationalmessaging system can be achieved by installing a broker 60′ on a testingand debugging system that is linked to the development system, andhaving the debugger automatically go through the deployment procedureeach time the developer clicks the “run” button. Messages 300 can besent to the debug broker 60′ in order to launch the execution of amessage flow 80 on a specific message.

[0128] A preferred solution is to leave the runtime environmentsubstantially unchanged, and introduce special “debug instructions” intothe message flow 80 being tested. To achieve this, the special debugnodes 210 (mentioned previously in relation to FIG. 5) have beendesigned and implemented. When the developer wishes to debug a messageflow, the development environment automatically instruments the originalmessage flow with these debug nodes, inserting a debug node betweenevery two connected original processing nodes and after every outterminal of a debug node that is not connected to any other node. Thisinstrumented flow is then deployed to the testing and debugging system,and is executed in the same manner as any other message flow. Theruntime environment is oblivious to the fact that this flow is beingmonitored.

[0129] The special debug nodes 210 issue calls to the debug controller240 via a communication manager (the debug controller, which is part ofthe development environment, usually resides on a different machine fromthe program being executed), passing information about the executionstatus (reporting the occurrence of exceptions), execution positionincluding the identity of the debug node, and an XML version of thestructure and contents of the message currently being propagated throughthe message flow. This data is sent each time a debug node is reachedduring execution (but alternative implementations are possible—seelater). The debug controller responds to breakpoints and programmeractions and then returns control to the execution engine 230.

[0130] The debug nodes according to this first embodiment of theinvention retain no information about a message after processing themessage—merely passing information to the debug controller whichaccesses information about breakpoints and the structure of the messageflow. A message flow is stored in the debug controller as a DOM(Distributed Object Model) element in XML, and this element includes thehierarchical structure of the message flow. The root element is themessage flow and this contains child elements for every node andconnection in the message flow. For compound nodes, such a child elementcan also be hierarchical—i.e. containing child elements that representits contained nodes and connections. Every node in this structure has aunique ID attribute. When the debug controller communicates with thedebug node, this ID is sent from the debug node to the debug controller,enabling it to identify the location of execution within the messageflow.

[0131] The debug controller stores the information received from debugnodes in an area of storage corresponding to an execution stack, and cancompare the current position in the execution stack with the previouslystored information structure of the message flow to determine thecurrent position within the message flow. A visual representation of themessage flow is constructed by inspecting the message flow structure anddrawing a node icon for each node and a link for each connection. Avisual representation of the current execution position within themessage flow preferably involves displaying an icon adjacent theposition of a breakpoint when the execution reaches that breakpoint.

[0132] The implementation described above is acceptable for embodimentsin which only one message is passing through a message flow at any time.An alternative implementation is available for more complex messageflows with multiple input nodes and/or complex nesting of filter nodes,which reduces communication delays between system components byproviding debug nodes with a “breakpoint” attribute such that they donot need to communicate with the debug controller to establish whetherthey are breakpoints. If debug nodes themselves can also keep track ofthe execution stack, they can communicate with the debug controller whena breakpoint is reached such that the stack can then be displayed to theprogrammer at the breakpoints. The debug nodes 210 still update theircopy of the stack every time a debug node is reached, but the stack'scurrent state is only transmitted to the debug controller 240 atbreakpoints. The reduction of communication of this implementation maybe balanced by greater complexity implementing dynamic changes to amessage flow while a message is being propagated, including to changebreakpoints while the flow is stopped at a breakpoint.

[0133]FIG. 7 shows an example message flow that a developer may want todebug. FIG. 8 shows the same message flow instrumented with the specialdebug nodes 210. A debug node is added on every connection connectingtwo processing nodes 220, and also added on every out port that is notconnected.

[0134] Advantages of this approach are:

[0135] The runtime environment (which may be complex) can be leftunchanged.

[0136] The changes/additions required to the message flow authoringenvironment are small.

[0137] Debugging capabilities are achieved using the same concepts ofprocessing nodes, so there is no need to introduce new specialmechanisms for debugging and monitoring.

[0138] The runtime environment does not require different modes forregular execution and debug mode to enable instrumented flows to beexecuted in parallel to regular flows.

[0139] A debug node has one in port, and one out port. Usually, thedebug node propagates the message received on the in port to the outport, and does not change the message. For debugging purposes, thedebugger user may edit the message in the debugger. In this case, thedebug node receives the edited message from the debugger, and propagatesthis changed message to the out port.

[0140]FIGS. 9 and 10 show the communication protocol between a debugprocessing node and the debug controller, when a debug node isencountered by the runtime engine.

[0141] Monitoring execution of hierarchical message flow

[0142] Message flows are developed using an hierarchical paradigm. Amessage flow is built of message processing nodes which in turn can bemessage flows. These are denoted compound message processing nodes.Compound message processing nodes are similar to subroutines inconventional programming languages. When a message flow is deployed, itgoes through a process of flattening, similar to inlining forconventional code. The result is a flat message flow in which allcompound nodes have been expanded. The flattened flow is the flowactually executed, while the developer conceptually expects the flow tobe executed as a nested hierarchy, i.e. when a compound message flow isencountered a “function call” is expected to occur to start asubroutine.

[0143] The present invention provides a solution to the problem of howto present the programmer with a hierarchical view of the execution,despite the hierarchical structure being hidden in a flattened messageflow and despite the likelihood that the message flow will be executedon a system remote from the control centre.

[0144] A conventional solution would be to install a debugger on thesame system as the program will be executed on, such that the executionstack of a hierarchical program flow being monitored is available todetermine a current position within the hierarchical flow. Each time aprocessing node is executed, the flow corresponding to a “subroutine”(the inner flow at this nesting level of the overall hierarchical flow)is pushed onto the stack, and it's diagram replaces the diagram of the“calling” flow. However, the conventional execution stack is notavailable to a remote debug controller and in the present embodiment,the system used for test execution and the system running the debuggerare interconnected but separate.

[0145] The present invention uses the progress report generator nodes210 to send execution progress information to the debug controller 240of the control centre, and the debug controller maintains informationrepresenting the hierarchical structure of the message flow, maps thereceived progress information to the hierarchical structure, andgenerates a visual representation of execution progress.

[0146] It is advantageous to limit the processing delays associated withsending the progress reports and yet the programmer wants as muchinformation as possible, so a balance is required as discussed above.Additionally, the semantics of execution of message flows requirecareful tracking of execution progress. Execution of a message flowfollows paths through the message flow. A path is a sequence ofprocessing nodes in the flattened message flow. When we try to trackthis path back to the original message flow, we see that the executionpath can leave a nesting level before all the processing in that levelhas finished. The example message flow of FIG. 11 demonstrates thissituation:

[0147] In this example, one possible execution sequence might be:

[0148] A: :InputQ→

[0149] B::InTerm→B::C→B::OutTerm→A::OutputQ-B::D.

[0150] As we can see, the execution path leaves the nested flow B beforenode B::D is executed. Execution later returns to B to finish theprocessing of node B::D. Making an analogy to conventional programming,this can be compared to a subroutine that can also be entered via a gotostatement.

[0151] A problem arises regarding how to display the execution stack tothe developer when such a “goto” situation occurs, if the only contextinformation received from a debug node is its identifier and the name ofits original containing flow.

[0152] A first solution according to an embodiment of the invention isbased on an execution algorithm which is adapted to facilitatemonitoring of message flows. According to this message flow executionalgorithm, execution proceeds forward in the sequence of messageprocessing nodes until an endpoint is encountered. When an endpoint isencountered, execution backtracks on the execution path until a newforward branch is found. Then execution proceeds forward on this newbranch, and so on.

[0153] In order to simulate and keep-track of the stack status duringthe execution of a flat flow, two execution stacks can be maintained,one for the forward direction, and the other for backtracking.

[0154] Forward Stack—keeps the execution depth status when execution isgoing forward.

[0155] Backward Stack—keeps the execution depth status when execution isgoing backward.

[0156] The debug node performs two communications with the developmentenvironment: once when it is entered (when execution is going forward)and once just before it is exited (when execution is backtracking).These “synchronization points” with the development environment are:

[0157] debugNodeReached—on entry

[0158] debugNodeExit—on exit

[0159] The following Boolean properties are defined for debug nodes:

[0160] afterin—a debug node that is immediately after an in terminal,i.e. on an edge coming out of an in terminal (immediately after acompound message flow is entered).

[0161] beforeOut—a debug node that is just before an out terminal, i.e.on an edge coming into an out terminal just before a compound messageflow is left).

[0162] beforeCompound—a debug node that is just before a compound node,i.e. on an edge coming into a compound node.

[0163] aftercompound—a debug node that is immediately after a compoundnode, i.e. on an edge coming out of a compound node.

[0164] The debug controller of the development environment keeps arecord of the “execution direction” which can be either forward orbackward.

[0165] The Forward Stack is the stack that is displayed to the developerat all times. The Backward Stack is only used to track the location ofthe execution in the hierarchical flow.

[0166] The algorithm that controls the nesting levels while executionproceeds along paths is as follows: Initialize both stacks to an emptystack Initialize direction to forward While not end of debug session ondebug node entrance if execution is going forward if ( debugNode.afterIn) push the current message flow to the Forward Stack if (debugNode.afterCompound ) pop a message flow from the Forward Stack else(execution is backtracking) direction = forward Forward Stack = BackwardStack on debug node exit if execution is going forward direction =backward Backward Stack = Forward Stack else (execution is backtracking)if ( debugNode.beforeOut ) push the current message flow to the BackwardStack if ( debugNode.beforeCompound ) pop a message flow from theBackward Stack

[0167] The advantages of this solution are that it requires a minimalamount of static analysis of the message flows and utilizes the existinginfrastructure.

[0168] In a second embodiment of the invention, which provides moredetail to the programmer, the example of FIG. 11 is modified to includean additional direct connection in C from the input terminal to theoutput terminal of C.

[0169] The execution sequence of FIG. 11 can then be represented asfollows:

[0170] Where MQInA is the input queue of message flow A; MQOutA is theoutput queue of A; InB is the input terminal of compound node B; OutB isthe output terminal of B; InC and OutC are the input and outputterminals of C; InD and OutD are the input and output terminals of D;and d1 to d11 are debug nodes.

[0171] A variant on the previous example is as follows:

[0172] There are three contexts from C in which D can get executed:

[0173] 1) InC -d3→C1 calls D

[0174] 2) InC -d3→C1-d4→C2 calls D

[0175] 3) InC -d12→C2 calls D

[0176] The solution according to this second embodiment does distinguish(2) from (1) and (3), but it does not distinguish between (1) and (3).It is desirable to hold on the context stack an indication of the nodethat causes the call to D, not just the fact that D was called. Thus, itis preferred that the ‘push’ of D onto the stack does not happen fromthe first debug point (d10) in D, but happens from the beforecompounddebug points in C (d3, d4 and d12).

[0177] This is a significant enhancement as flows get more complex, bothin the number of subflows and more particularly for instances of thesame subflow and different paths to the same subflow instances.

[0178] The system according to this embodiment is implemented with asingle stack that contains an identification of all ‘currentlyexecuting’ nodes. (Double stacks are only needed in implementations thatrequire backtracking).

[0179] A marker is included on the stack to indicate the differencebetween transfer within a flow and call to another flow. Although just asingle stack, it holds more information that the two stacks of the firstembodiment, as the markers effectively turn it into a stack (to identifynode hierarchy) of stacks (to identify exact flow context within currentand all calling compound nodes).

[0180] An ‘afterIn’debug node pushes a stack mark and an ID for itspredecessor node on entry, and pops them on exit.

[0181] A ‘before’ debug node pushes an ID for its successor node onentry, and pops it on exit.

[0182] (applies to beforeCompound, beforeOut and beforeSimple)

[0183] A node may stack more than one set of items: e.g. d3 is bothafterIn and BeforeCompound

[0184] Thus, the implementation of a debug node becomes: if afterIn then//′ push marker   ′ push id(previousNode)   ′ end   ′ entering traceinput information   ′ if before then   ′ push id(sucessorNode) //. callsucessorNode   ′ real call pop id(sucessorNode) //′ end   ′ trace returninformation   ′ exiting if afterIn then   ′ pop id(previousNode)   ′ popmarker //′

[0185] The stack will grow as follows:

[0186] d1>: MQInA B1

[0187] d3>: MQInA B1| InB C1|

[0188] d6>: MQInA B1| InB C1| InC D1

[0189] d10>: MQInA B1| InB C1| InC D1| InD X

[0190] d11>: MQInA B1| InB C1| InC D1| InD X OutD

[0191] d11<: MQInA B1| InB C1| InC D1| InD X

[0192] d10<: MQInA B1| InB C1| InC D1

[0193] d6>: MQInA B1| InB C1| InC D1

[0194] d3>: MQInA B1| InB C1

[0195] d1>: MQInA B1

[0196] This stack very closely models the run time method call stackthat exists in the broker during run-time execution.

[0197] Significant advantages of a message flow debugger according tothe preferred embodiments of the present invention are as follows:

[0198] 1. The ability to check the message flow as part of the messageflow development environment while working with concepts that arefamiliar to the message flow developer (i.e. processing nodes andmessages)

[0199] 2. The ability to inspect the message content at any point duringthe execution through the message flow

[0200] 3. Enabling the programmer to delay integrating the message flowto the production messaging system until it is verified as workingproperly.

[0201] This provides far better usability for programmers than thealternative of keeping a dedicated messaging system which is notconnected with the development system and is for debugging purposesonly. In this case, the developer will have to perform the debuggingbased on information he would have to extract from the log filesproduced by the message broker, if available at all.

[0202] An example usage scenario for an implementation of the inventionis as follows:

[0203] 1. Message flow developer moves to the debugger page in thedevelopment environment and selects a message flow to debug from thelist of available message flows.

[0204] 2. Select/define an input message that will be propagated throughthe message flow during the debug session. This message can be definedin several ways: by selecting a message type and then typing in itscontents or by reading an XML message from a file.

[0205] 3. In most cases, although this is not mandatory, the next stepusers will perform is to set one or more breakpoints on the message flowin order to track the message content. A breakpoint can be set on everyconnection between processing nodes or on an input/output port of aprocessing node.

[0206] 4. Run the message through the flow

[0207] 5. During the execution of the message by the broker theprogrammer can perform the following activities

[0208] Inspect the message content

[0209] Update the message content once the execution is stopped at oneof the breakpoints

[0210] Continue execution

[0211] Step over the following processing node

[0212] Step into the following processing node

[0213] Return

[0214] Restart

[0215] Quit execution

[0216] It will be appreciated by persons skilled in the art that thedetailed descriptions of preferred embodiments of the invention providedabove are by way of example only and that variations and modifications,including different combinations and subcombinations of the describedfeatures, are within the scope of the present invention as set out inthe claims.

What is claimed is:
 1. A visual execution monitoring tool for monitoringexecution of a message processing program, comprising: one or morecomponents for generating program execution progress reports uponreaching predefined stages of program execution, the execution progressreports including a representation of the current contents of a messagebeing processed by the message processing program, and for sending theexecution progress reports to an execution monitoring controller; anexecution monitoring controller which is responsive to receipt of saidexecution progress reports for generating, during execution of saidmessage processing program, a visual representation of the messagecontents.
 2. A visual execution monitoring tool according to claim 1,including a message generator which is responsive to user input tocreate a message and to invoke the message processing program to processthe message.
 3. A visual execution monitoring tool according to claim 1,including means for setting breakpoints within the message processingprogram and means for modifying the message contents when execution isstopped at a breakpoint.
 4. A visual execution monitoring tool accordingto claim 1, wherein the execution progress reports include an indicationof the current execution status and the execution monitoring controlleris adapted to generate a visual representation of the current executionstatus.
 5. A visual execution monitoring tool according to claim 1,wherein the execution progress reports include information relating tothe position within the message processing program structurecorresponding to the current stage of program execution and theexecution monitoring controller is adapted to generate a visualrepresentation of this position within the message processing programstructure.
 6. A visual execution monitoring tool according to claim 1,wherein the execution monitoring controller includes means for analyzingthe message processing program to identify a set of locations within themessage processing program corresponding to a predefined set ofexecution progress points and to insert the components for generatingprogram execution progress reports at said locations.
 7. A method formonitoring execution progress of a message processing program, includingthe steps of: identifying a set of locations within the messageprocessing program corresponding to a predefined set of executionprogress points, and inserting at each of said locations a component forgenerating a program execution progress report when the predefinedexecution progress point is reached during execution of the messageprocessing program; responsive to input to the message processingprogram of at least one message, initiating execution of the messageprocessing program to process said at least one message and to generateprogram execution progress reports including a representation of thecurrent message contents, and to send the reports to an executionmonitoring controller; responsive to receipt of said progress reports bysaid execution monitoring controller, generating a visual representationof the current message contents for display to a user.
 8. A computerprogram product comprising program code recorded on a computer-readablerecording medium, for monitoring execution of a message processingprogram, comprising: one or more components for generating programexecution progress reports upon reaching predefined stages of programexecution, the execution progress reports including a representation ofthe current contents of a message being processed by the messageprocessing program, and for sending the execution progress reports to anexecution monitoring controller; an execution monitoring controllerwhich is responsive to receipt of said execution progress reports forgenerating, during execution of said message processing program, avisual representation of the message contents.
 9. A data processingsystem including a visual execution monitoring tool for monitoringexecution of a message processing program, the execution monitoring toolcomprising: one or more components for generating program executionprogress reports upon reaching predefined stages of program execution,the execution progress reports including a representation of the currentcontents of a message being processed by the message processing program,and for sending the execution progress reports to an executionmonitoring controller; an execution monitoring controller which isresponsive to receipt of said execution progress reports for generating,during execution of said message processing program, a visualrepresentation of the message contents.
 10. A visual executionmonitoring tool for monitoring execution of a message processingprogram, the execution monitoring tool comprising: means for identifyinglocations within the message processing program corresponding to apredefined set of execution progress points, and for inserting at eachof said locations a component for generating a program executionprogress report when the predefined execution progress point is reachedduring execution of the message processing program; means responsive toinput to the message processing program of at least one message, forinitiating execution of the message processing program to process saidat least one message and to generate program execution progress reportsincluding a representation of the current message contents, and to sendthe reports to an execution monitoring controller; means responsive toreceipt of said progress reports by said execution monitoringcontroller, for generating a visual representation of the currentmessage contents for display to a user.
 11. A computer program productcomprising program code recorded on a computer-readable recordingmedium, for monitoring execution of a message processing program,comprising: means for identifying locations within the messageprocessing program corresponding to a predefined set of executionprogress points, and for inserting at each of said locations a componentfor generating a program execution progress report when the predefinedexecution progress point is reached during execution of the messageprocessing program; means responsive to input to the message processingprogram of at least one message, for initiating execution of the messageprocessing program to process said at least one message and to generateprogram execution progress reports including a representation of thecurrent message contents, and to send the reports to an executionmonitoring controller; means responsive to receipt of said progressreports by said execution monitoring controller, for generating a visualrepresentation of the current message contents for display to a user.12. A data processing system including a visual execution monitoringtool for monitoring execution of a message processing program, theexecution monitoring tool comprising: means for identifying locationswithin the message processing program corresponding to a predefined setof execution progress points, and for inserting at each of saidlocations a component for generating a program execution progress reportwhen the predefined execution progress point is reached during executionof the message processing program; means responsive to input to themessage processing program of at least one message, for initiatingexecution of the message processing program to process said at least onemessage and to generate program execution progress reports including arepresentation of the current message contents, and to send the reportsto an execution monitoring controller; means responsive to receipt ofsaid progress reports by said execution monitoring controller, forgenerating a visual representation of the current message contents fordisplay to a user.
 13. A visual execution monitoring tool for monitoringexecution of a computer program, comprising: means for identifyinglocations within a computer program corresponding to a predefined set ofexecution progress points, and for inserting at each of said locations acomponent for generating program execution progress reports when thepredefined execution progress points are reached during execution ofsaid program; means responsive to said components generating saidexecution progress reports for sending the progress reports to anexecution monitoring controller; an execution monitoring controller forreceiving said execution progress reports and for generating, duringexecution of said computer program, a visual representation of thereceived execution progress report data.
 14. A visual executionmonitoring tool according to claim 13, including means for settingbreakpoints during program execution, wherein the identified locationscorresponding to a predefined set of execution progress points comprisesall possible breakpoint locations within the computer program.
 15. Avisual execution monitoring tool according to claim 13, wherein theexecution progress reports include execution status information andinformation relating to the position within the program structurecorresponding to the current stage of program execution, and wherein theexecution monitoring controller is adapted to generate a visualrepresentation of the position within the program structure and a visualrepresentation of the execution status information.
 16. A visualexecution monitoring tool according to claim 13, in which said executionmonitoring controller maintains a representation of the structure of thecomputer program as a sequence of interconnected nodes in whichindividual nodes represent processing components of the program, andwherein the progress reports include an identifier of a node associatedwith the currently executing processing component.
 17. A visualexecution monitoring tool according to claim 16, wherein the informationrelating to the position within the program structure includes a nodeidentifier and the execution monitoring controller saves thisinformation to an execution stack so as to record information tracking asequence of positions within the program structure corresponding to anexecuted processing sequence.
 18. A visual execution monitoring toolaccording to claim 16, in which the components for generating progressreports are also represented as nodes within the program structure.